fix: map runtime modes to correct permission levels#1587
fix: map runtime modes to correct permission levels#1587oski646 wants to merge 3 commits intopingdotgg:mainfrom
Conversation
…pt-edits mode Sessions launched without --dangerously-skip-permissions crashed when switching away from full-access because the fallback always tried to restore bypassPermissions. Map each runtime mode to its proper Codex approval policy / sandbox pair and Claude SDK permission mode, and expose the new auto-accept-edits option in the UI. Fixes pingdotgg#1437 Fixes pingdotgg#1241
|
Important Review skippedAuto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Repository UI Review profile: CHILL Plan: Pro Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
🔴 Critical
t3code/apps/web/src/components/ChatView.tsx
Line 259 in d9ec964
The new "auto-accept-edits" runtime mode is silently discarded by setRuntimeMode in composerDraftStore.ts, which only recognizes "approval-required" and "full-access" as valid values. When cycleRuntimeMode transitions to "auto-accept-edits", the call setComposerDraftRuntimeMode(threadId, "auto-accept-edits") converts the value to null, causing the mode to fall back to the thread default instead of persisting the user's selection.
🤖 Copy this AI Prompt to have your agent fix this:
In file apps/web/src/components/ChatView.tsx around line 259:
The new `"auto-accept-edits"` runtime mode is silently discarded by `setRuntimeMode` in `composerDraftStore.ts`, which only recognizes `"approval-required"` and `"full-access"` as valid values. When `cycleRuntimeMode` transitions to `"auto-accept-edits"`, the call `setComposerDraftRuntimeMode(threadId, "auto-accept-edits")` converts the value to `null`, causing the mode to fall back to the thread default instead of persisting the user's selection.
Evidence trail:
packages/contracts/src/orchestration.ts lines 65-69: RuntimeMode is defined with three literal values: "approval-required", "auto-accept-edits", "full-access"
apps/web/src/components/ChatView.tsx lines 250-270: RUNTIME_MODE_CONFIG includes all three modes in the UI cycle
apps/web/src/composerDraftStore.ts lines 1800-1805: setRuntimeMode function implementation only recognizes "approval-required" and "full-access" in the condition `runtimeMode === "approval-required" || runtimeMode === "full-access"`, converting any other value (including "auto-accept-edits") to null
There was a problem hiding this comment.
Sorry, I'm unable to act on this request because you do not have permissions within this repository.
setRuntimeMode had an explicit allowlist that missed "auto-accept-edits", converting it to null. Replace with nullish coalescing since TypeScript already constrains the parameter to RuntimeMode | null | undefined.
What Changed
I fixed running Claude in Supervised mode. Fixing that also made me think we should adjust it for the Codex adapter. I also introduced a new mode inspired by the Claude CLI called “Auto accept edits”. I did not know how to handle the fix without adding this mode because having just "Supervised" which should be read only or full accept mode for the user (to my understanding), and "Full Access" which is a full bypass mode, is probably not enough for some users. Adding this one more mode was low hanging fruit for me, so I thought I could do it here as well. I tried to keep everything simple and focus only on fixing the bug and adding this one mode.
I am not sure if the change to the test, running it in a for loop, is necessary. I am open to suggestions about this and, of course, other changes I made.
I also noticed some other things that could be improved related to that change, but I did not want to make this PR big and difficult to review.
Why
Sessions launched without --dangerously-skip-permissions (Claude) crashed when switching away from full-access because the fallback always tried to restore bypassPermissions. Map each runtime mode to its proper Codex approval policy / sandbox pair and Claude SDK permission mode, and expose the new auto-accept-edits option in the UI.
Fixes #1437
Fixes #1241
UI Changes
The only change to UI is new "Auto-accept edits" mode added. Nothing else.
Checklist
Note
Medium Risk
Changes enforcement of sandbox/permission levels for agent runtimes and introduces a new access mode, which could affect what actions are allowed/blocked in real sessions. Risk is moderate because it touches safety/authorization behavior but is scoped and covered by updated tests/UI wiring.
Overview
Fixes runtime-mode permission mapping across providers and UI.
approval-requirednow maps to read-only/untrusted for Codex and Claude no longer falls back tobypassPermissionswhen restoring fromplanback todefault.Adds a new
RuntimeModevalue,auto-accept-edits, mapped to workspace-write/on-request for Codex andacceptEditsfor Claude, and updates the chat UI to cycle/select among Supervised → Auto-accept edits → Full access (including icons/tooltips) while persisting the new mode in drafts.Written by Cursor Bugbot for commit 364cd56. This will update automatically on new commits. Configure here.
Note
Fix runtime mode to permission level mappings and add
auto-accept-editsmodeauto-accept-editsas a newRuntimeModeliteral betweenapproval-requiredandfull-access, enabling a three-step cycle in the UI instead of a binary toggle.mapCodexRuntimeModein codexAppServerManager.ts:approval-requirednow correctly maps toapprovalPolicy: 'untrusted'/sandbox: 'read-only'instead ofon-request/workspace-write.auto-accept-editsmaps toapprovalPolicy: 'on-request'/sandbox: 'workspace-write'and initializes Claude sessions with permission modeacceptEdits.approval-requiredsessions now get read-only sandbox access; previously they received workspace-write access.Macroscope summarized 364cd56.